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ABSTRACT 



A data capture system is disclosed as comprising a plurality 
of client data collection terminals, and a server station. Each 
terminal including a mechanism for collecting data, a 
dynamic addressable memory and a first controller operating 
on data formatted in a first style. The server station com- 
prises mass memory, which is larger than the dynamic 
addressable memory of a terminal for storing data to be used 
by the data collection terminals, an addresser responsive to 
a memory altering request for addressing the mass memory 
and a second controller operating on data formatted in a 
second style different from said first style. The data stored in 
the dynamic addressable memory is formatted in the second 
style, A communication system interconnects the server 
station and each of the plurality of client data collection 
terminals. The first controller of each cUent data collection 
terminal is responsive to a need for further data to generate 
a memory altering request and for actuating the communi- 
cation system to transmit the generated request to the server 
station. The request is generated to identify its terminal and 
the particular needed data. The second controller of the 
server station is responsive to the transmitted request to 
address and retrieve the needed data from the mass memory 
before actuating the communication system to transmit the 
needed data back to the requesting terminal as identified by 
the request. 

17 Claims, 9 Drawing Sheets 
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VERSATILE RF DATA CAPTURE SYSTEM 

CROSS-REFERENCE 

The present application is a continuation of U.S. appli- 
cation Ser. No, 08/267,758 (Attorney Docket No. 
DN37613A), filed Jul. 5, 1994, by Michael D. Morris et al., 
(now U.S. Pat. No. 5,568,645) which is a continuation of 
U.S. application Ser. No. 07/748,150 (Attorney Docket No. 
DN37613). filed Aug. 21. 1991. now U.S. Pat. No. 5.349, 
678. 

AUTHORIZATION PURSUANT TO 37 CFR L71 
(d) AND (e) 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protection. 
The copyright owner has do objection to the facsimile 
reproduction by anyone of the patent document or the patent 
disclosure, as it appears in the Patent and Trademark Office 
patent file or records, but otherwise reserves all copyright 
rights whatsoever. 

REFERENCE TO RELATED, CO-PENDING 
PATENT APPLICATIONS 

The following, co-pending applications are all assigned to 
assignee of this invention and are incorporated herein by 
reference: 

1. U.S. Ser. No. 700704 (Express Mail Label No.: FB 537 
394 682US), entitled "SYSTEM FOR COUPUNG A 
MULTIPLICITY OF RF DATA COLLECTION TER- 
MINALS WITH HOST COMPUTER MEANS" filed 
on May 14, 1991 in the names of GoUnick et al. 
(Attorney Docket No. DN37834X) now abandoned in 
favor of U.S. Ser. No. 07/857,603, filed Mar. 30, 1992 
(Attorney Docket No. DN36834XA), now abandoned 
in favor of U,S, Ser. No. 07/947,102 filed Sep. 14, 1992 
(Attorney Docket No. DN37834XXB); and 

2. U.S. Ser. No. 660618 (Express Mail mailing Label No.: 
FB 537 394 671US), entitled "SYSTEM FOR PRO- 
CESSING COMMUNICATIONS WITH MULTIPLE 
PORTABLE RF DATA COLLECTION 
TERMINALS", filed Feb. 25, 1991 in the name of P 

Miller (Attorney Docket No. 37734) now abandoned in 
favor of U.S. Ser. No. 07/830,561, filed Jan. 30, 1992 
(Attorney Docket No. DN37734A. 

BACKGROUND OF THE INVENTION 

The present invention relates to a data capture system 10 
illustrated in FIG. 1 for entering data at a plurahty of remote 
locations using means such as a plurality of portable data 
collection terminals 12a, h-n. The data capture system 10 is 
applicable to receive and collect a wide variety of data and 
has found particular application in warehouses or retail store 
where a data capture system 10 would be used to keep an 
up-to-date record of the products to be marketed. Typically, 
the system 10 would be capable of updating on a real time 
basis the inventory count of products, and to use stock 
locator data to identify where each product of the remaining 
inventory is stored, when a product is moved from one place 
to another, and which employee has current charge of that 
product. In addition, when a product is sold, the price and 
sales person who sold the product are recorded. 

Such data may be inputted into a terminal 12 by means of 
its keyboard 13. For example, a terminal user could count 
the number of one type of product and enter that number via 
the tenminars keyboard 13. Alternatively, data could be 
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entered to the terminal 10 via a CCD bar code scanner 22. 
which is electrically coupled by a cable 20 to its terminal 12. 
In an illustrative embodiment of this invention, the scanner 
as illustratively identified in FIG, 1 by the numeral 22a and 

5 its terminal 12a could take the form of that modular scanner/ 
terminal described in PCT international application W090/ 
16033 published Dec. 27, 1990. Differing types of scanners 
22^ and 22n could also be used witl the terminals 12 and 
may illustratively take the form of those scanners described 

IQ in U.S. Pat. Nos. 4,970,379 of Danstrom, 4,882,476 of 
White, 4,894,523 of Chadima. 4,877,949 of Danielson et al., 
5,019,669 of Adams et al. and 4,924,462 of Sojka; Interna- 
tional AppHcation No. PCT/US90/03282 of Koenck et al.; 
and European Patent Publication No. 0, 353, 759 of Mahany 

15 

The data capture system 10 utilizes illustratively RF 
transmission to bilaterally transmit data between each of the 
plurality of terminals 12fl, b-n and a base radio transceiver 
14. By way of example, the base radio transceiver may 

20 illustratively take the form of thai model RB3000 base radio 
transceiver manufactured by Norand Corporation, Cedar 
Rapids of Iowa. In turn, the base radio transceiver 14 is 
connected via a communications multiplexer 16a or a com- 
munications controller 16b to a host computer 18. 

25 Illustratively, the multiplexer 16a could take the form of that 
model RM3200 as manufactured by Norand Corporation 
and the controller 16b could take the form of that controller 
identified as model RC2250 of Norand Corporation. The 
host computer 18 may illustratively be an International 

30 Business Machines Corporation of AT class or higher As 
illustrated in FIG. 1, the host computer 18 includes a 
keyboard 28, a display 24 and a system unit 26. 

Each of the portable data collection terminals 12a, b-n 
includes a transceiver (not shown in FIG. 1) for transmitting 

35 RF messages to and from the base radio transceiver 14. A 
transmitted message comprises an initialization sequence, an 
address indicative of the particular terminal 12a, b-orn from 
or to which the message is directed, a message identifier and 
system information, the message data and/or control 

40 commands, enor control, and an end of message indication. 
U.S. Pat, Nos. 4,910,794; 4,924,462; and 4,940,974, each 
assigned to the assignee of this invention and incorporated 
herein by reference, provide further information on RF data 
collection terminals and systems. 

45 In a RF data capture system similar to that shown in FIG. 
1 known as the RT1200 system of Norand Corporation, 
controlled RF transmission between a plurality of terminals 
and a radio base is established using a communications 
multiplexer similar to that of the multiplexer 16a shown in 

50 FIG. 1 to provide access to a particular one of the terminals 
12a, b-n. The RT1200 system utihzes time division multi- 
plexing on a single frequency channel. The RT1200 com- 
munications protocol is based on a sequential polling 
method that transmits a query addressed to each portable 

55 terminal in succession, and allows a specified amount of 
time for the addressed terminal to respond when the 
addressed terminal has a data message ready for transmis- 
sion. U.S. Pat. No. 4,940,974 describes an improved, adap- 
tive data communications system wherein the base radio 

60 transceiver 14 transmits a multi -terminal polling signal to 
each of its terminals Ma, b-n. That multi-terminal polling 
signal defines a series of successive response time slots in 
which the terminals 12 may randomly select to respond. A 
terminal 12 having a message to be transmitted to the host 

65 computer 18 via the base radio transceiver 14 transmits a 
brief response burst in the selected time slot giving its own 
unique identification address. After receiving the responses 
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from the ready terminals 12, the base radio transceiver 14 services, the application program makes a procedure call 

polls each of the responding terminals 12, ignoring those that is like any procedure call to the program's code. The 

terminals without messages to be transmitted. This system is difference is that the call results in a request to a remote 

adaptive in that the number of time slots may be changed system to provide the computation designated by the call 
depending upon the number of active terminals ready to 5 The concept of pipes relates to supplying the output of one 

transmit data messages. process to the input of another process. If the two processes 

-Rie present invenlion is particularly related to adapting °" ^i^^^*^"* computers then this becornes a rnethod of 

such data capture system 10 as shown in FTG. 1 to employ distnbuted processmg. Avanant of this method is the named 

distributed processing concepts. Each of the portable data P^^r,*^:?!;""^^ ^h' cT h ° "Z^tl 
. , A. ^ , f in process over a named connection. This is the primary 
coucclion terminals U Has a computer processing capability - 1^,^,^^ distributed interprocess communications with an 

in the illustrative form of a microprocessor, whereby the Mana er 

entire system's processing capabQity may be distributed rr^^ ^ ■ 

between the host computer 18 and the portable terminals 12. ^ffi^^'^"' transmission of data to a remote terminal of 

Tlie system 10 is structured in accordance with a client/ f '^'''"."^k 7in '""'TnrfxA^^' ' "^'"T " 
server architecture whereby the host computer 18 acts as a 15 'heir Distributed Data Management (DDM) protocoU^These 

servertoeachof the plurality of clientterminalsl2, whereby " ^' °^ P"!'''^''ed IBM protocols that describe how to 

programs may be dynamically loaded across that RF (or any f^""^ f databases on a remote system. BM alsode- 

serial) data link established between the host computer 18 "^^"^^^ * Application Architecture (SAA) with 

and its terminals 12. common programming interfaces for program access to 
„ ^ ., , ... . , ,20 remote data on IBM SAA compliant systems. The impor- 

Tlic use Of distributed proce^mg is enhanced by rela- ^^^^ j^ese protocols (which use LU 6.2 protocols for 

tional database technology and the use of Structured Query inter-system communication) is that a remote system such as 

Language (SQL) developed by the International Business ^ ^^y access IBM host databases and files without 

Machines Company to provide access to relational data- ^^^^^^ p^^gram the host computer. 

bases. The use of relational database technology depends on d^™*- a^*^ «™^c ;« mxx v 

, . i_ i_i 25 Remote data access in the non-IBM world is also becom- 

organizing data in tables (or relations); each row of the table • » j j -ru m * i rr-i e . /ktt-otmn . i 

^ . , , t * -t- * ing standard. The Network File System (NFS™) protocols 

represents a record and each column represents an attnbute. , j u o , u « i j • li- 

. I. r J *i. 1 .* J (developed by Sun Microsystems but placed in the public 

Va nous operations may be performed on these relations and, \ . f ^ /^i * 

. . . , domain) may be used to access or create files on any system 

since the mathematics of these operations is very well . kt n o * ■ i j- 

.... . J- * uf 4 1 ^.u running an NFS server. Novell Corporation is also providing 

understood, the results are predictable. An example of these • i • . j r . -.l ^ i_i 

. . . H^^"*^^**^*^- iii^t similar services to a wide range of systems with its portable 

operations is the "join , where two or more relations may be Netware''" 

put together based on some common attribute. The ad van- , . , . , ^ 

tage of this organization is that data may be easily retrieved I" cu"«t data cap ure sys ems employmg a plurality of 

in a form not envisioned by the designers; that is, ad hoc f'""'* ""^ ^-PP^tion program is run in the 

retrievals are quite easy to perform. centrally disposed hos computer 18 for real time control of 
, , . . 35 the remote terminals 12. Placmg control in the host com- 

A further concept of distributed processing is to partition jg significantly the hardware and software 

the system so that data is available to all network iisers but complexity forcing the host computer 18 to run multiple 

the data physicaUy resides where it u; most Ukely to be processes. Such application programs residing in the host 

processed. TTiis provides universal access without incumng computer 18 are complicated by the need to assure the 

severe communication overhead penalties. In the context of concurrent control over shared data. Further, the host com- 

the data capture system 10 lUustrated m FIG. 1, data is made p^j^^ fast enough to service aU remote terminals 

available to each of the termmals 12 and to the host 12 in real time. In such current data capture systems, the host 

computer 18 by the use of the RF transmission between each computer 18 must normally validate data entry by the user 

of termmals 12 and the base radio transceiver 14. However, ^^^j nj^s, ^^^^^^^ j„ ^i, i„p„,_ j^us squiring significant 

employing the concept of distnbuted processmg would ^^^^^ „j j^,^ ^^ ^^„t ^^ck and forth over an RF link 

direct that more data and application programs be stored between each of the terminals 10 and its host computer 18 

withm each of the termmals 12, where such data is used or ^3 increasing the number of data transition session 

such programs executed. As a result, overtiead penalties, between the host computer 18 and its terminals 12. 

primarily in terms of delays as would ocair by the trans- ^^^^^ j^^^^,;^^ ^ distributed 

mission 01 data between the terminals 12 and its host . t-nr-j. , .ia 

. 50 processing concepts in a Rr data capture system 10 as 

computer 18 are avoided. generally shown in FIG. 1 and in particular to improve the 

In a client/server model, the server provides a general efficiency of such overaU systems by improving the speed 

function to several client processes. Some of the more useftil ^nd efficiency of data transmission over the RF link between 

implementations of this concept are distributed databases, ^ach of the terminals 12a, and the base radio transceiver 

remote procedure calls and networked pipes. The distributed 55 14 

databases currently rely on some form of communication 

through Structured Query Language (SQL). These databases SUMMARY OF THE INVENTION 

are comprised of front-end applications and a database It is therefore an object of this invenlion to decrease the 

server. The application interacts with the user. When data- response time required for a portable data collection tcrmi- 

base access is required, the application sends an SQL request to respond to its user. 

to the database server which services the request across a It is a further object of this invention to minimize the data 

network. This allows most of the processing to be done transmitted typically by RF transmission between each of a 

locally, but provides for a central data store that may be plurality of terminals and its centrally disposed host com- 

shared by many distributed users. puter. 

The remote procedure call concept allows systems to 65 It is a still further object of this invention to eliminate 

become specialized servers so that many applications may programming the host computer for real time control of its 

use their specialized hardware. To access these remote plurality of data collection terminals. 
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It is another object of this invention to provide an envi- FIG. 5 is a flow diagram of the Program Manager program 

ronment for the ready developmenl of application programs shown in the architecture diagram of FIG. 4; 

for each of a plurality of data coUection terminals. pjQ 5 ^ fl^^ diagram of the Transaction Manager 

It is a still further object of this invention to provide a new program shown in the architecture diagram of FIG. 4; 

and improved scheme of distributive processing between a 5 cTr-T- r. *• lui ij- r *u ^ * u 

central or host computer and a plurality of remofe terminals. J^^'^ is a ftmctional block diagram of the database server 

I* *ii c .u u- * f.u- • *■ * A shown in FIG, 2; 

It still a further object of this invention to provide a new 

and improved battery operated terminal for se in a data FI^. 8 is a diagrammatic showing of the architecture of 

capture system comprised of a plurality of such terminals, database server memory; and 

wherein the drain imposed by large memory and frequent jq FIG. 9 is a flow diagram of the Presentation Manager 

use of radio modules is minimized. program shown in the architecture diagram of FIG, 8, 

In accordance with these and other objects of the nFsrRiPTiniM OP thf prfffrrfh 

invention, a dau capture system comprises a plurality of ™^ 
client data collection terminals, and a server station. Each 

terminal includes a mechanism for collecting data, a 15 Referring now to the drawings and. in particular to FIG. 
dynamic addressable memory and a first controller operating 2, there is shown a data capture system 110 in accordance 
on data formatted in a first style. The server station com- with the teachings of this invention, where elements similar 
prises a mass memory, which is larger than the dynamic to those of FIG.l are identified by like numerals but in the 
addressable memory of a terminal for storing data to be used 100' s series. The data capture system 110 includes a plu- 
by the data collection terminals, an addresser responsive to 20 rality of portable data collection terminals 112a, b-n, which 
a memory altering request for addressing the mass memory in an illustrative embodiment of this invention may take the 
and a second controller operating on data formatted in a form of that terminal RTIOOO as manufactured by Norand 
second style different from said first style. The data stored in Corporation. Each terminal 112 includes, as shown in FIG3, 
the dynamic addressable memory is formatted in the second a radio module 152 which is capable of receiving and 
style. A communication system interconnects the server 25 transmitting RF signals to a base radio transceiver 114, 
station and each of the plurality of client data collection which may illustratively take the form of that model 
terminals. The first controller of each client data collection RB3000 base radio transceiver as manufactured by Norand 
terminal is responsive to a need for further data to generate Corporion. The RB3000 base radio transceiver 114 is 
a memory altering request and for actuating the communi- capable of operating at multiple baud rates as described in 
cation system to transmit the generated request to the server 30 U.S. Pat. No, 4,910,794. In turn, the received signals are 
station. The request is generated to identify its terminal and transmitted to a database server 130, which in response to 
the particular needed data. The second controller of the the received signals applies signals to the base radio trans- 
server station is responsive to the transmitted request to ceiver 114 to be transmitted to a selected one of the plurality 
address and retrieve the needed data from the mass memory of the terminals 112. Each message transmitted between one 
before acting the communication system to transmit the 35 of the terminals 112 and the transceiver 114 includes an 
needed data back to the requesting terminal as identified by identification number or ID indicating the originating ter- 
the request. minal 112 or its user. In turn, the database server 130 is 
In a further aspect of this invention, each of the plurality coupled to a host computer 118. In an illustrative embodi- 
application programs is partitioned into a root module and at ment of this invention, the host computer 118 may take the 
least one overlay module. The first controller of each ler- 4D form of an IBM 3090 main frame with a DB2 database 
minal includes a processor for executing a selected appli- engine. As will be explained in detail below, each terminal 
cation of the plurality and is responsive to the execution of 112 is programmed to compose an SQL request that will 
an application program to generate the memory altering cause the database server 130 to return an application 
request and for actuating the communication system to program, a memory overlay or application specific data to 
transmit the generated request to the server station. The 45 the requesting terminal 112. The host computer 118 may also 
request identifies its terminal and the particular overlay access the database server 130 by generating and transmit- 
module needed to continue the execution of its application ting SQL request messages thereto. 

program. The second controller of the server station is The host computer 118 has a database, which is accessible 
responsive to transmitted request for addressing and retriev- through the database server 130 to respond to the SQL 
ing firom its mass memory the particular overlay module, 50 request from one of the terminals 112, supplying to the 
before actuating the communication system to transmit the requesting terminal 112 a computer program, memory over- 
particular overlay module back to the requesting terminal. lays or application specific data. The host computer 118 may 
BRIEF DESCRIPTION OF THE DRAWINGS illustratively take the form of an IBM 3090 main frame with 

a DB2 database engine and would have a memory of a 

FIG. 1 is diagrammatic illustration of an existing prior art 55 capacity many orders greater than that of the terminals 112. 

data capture system which may be upgraded to incorporate ^^y^h of the data Ed software to be used by* terminals 112 

features of the present invention; ^ot be stored with in the terminates memory, but rather 

FIG, 2 is diagrammatic illustration of a data capture may reside in the database of the server 130 or in the 

system configured in a client/server architecture to effect memory of the host computer 118. Thus, when that data 

distributed processing in accordance with the teachings of 50 and/or program stored in the database server 130 is needed, 

this invention; the needing terminal 112 formulates its SQL request 

FIG, 3 is a functional block diagram illustrating the message, transmits that message via the base radio irans- 

architecturc of a portable data collection terminal as shown ceiver 14 to be processed by the database server 130, which 

in FIG. 2; accesses its database (or the memory of the host computer 

FIG. 4 is diagram of the application program architecture 65 118) and retransmits the requested data or programs back to 

as stored within the ROM of the portable data collection the requesting terminal 112. At least two tables are defined 

terminal shown in FIG. 3; as shown in FIG. 7 in a memory of the database server 130 
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including a first program table 139 and a second authoriza- 
tion table 141. The program table 139 keeps track of all of 
the programs, the overlays and the locations where they are 
stored in the database of the server 130. The programs are 
typically stored as a "bulk" or "binary" data type. The 
program table requires at a minimum the following fields or 
attributes: 



attribute 


type 


description 


program name 


char 


Name of the program 


overlay 


char 


root or other named overlay 


date 


char or date 


Date program was created (revision 






control) 


program 


varbtnary or 


The actual program or overlay 




varchai 




size 


integer 


The size of the binary to be loaded 



10 



As will be explained later with respect to FIG. 7, the first, 
program table 139 and the second, authorization table 141 
may be established within a hard disk drive 137 of the 
database server 130. The SQL request includes an attribute 
to identify whether a new program or an overlay is to be 
accessed and sent by the requesting terminal 112, and the 
address or name of the first, program table 139. The SQL 
request does not need to have the address of the requested 
program or overlay, but accesses the program table 139, 
which provides an address within the hard disk drive 137 in 
accordance with the attribute. As will be explained, the 
database server 130 in response to the SQL request accesses 
a particular program or overlay and transmits it back to the 
requesting terminal 112. The second authorization table 141 
identifies the relationship between a particular user and each 
of the programs which that user is authorized to access. For 
example, each user has an ID and the authorization table 141 
would list the program names which may be accessed by that 
particular user ID. Similarly, the SQL includes the ID and an 
address for the authorization table 141. Thus, the SQL 
request accesses the authorization table 141 to see if the 
requesting terminal 112 or its user as identified by the ID is 
permitted to use a particular program or overlay. If there is 
a match between the ID and one of the listed programs 
stored in the authorization table 141, then as will be 
explained, the database server 130 will access that program 
or overiay and transmit it back to the requesting tenminal 
112. On the other hand, if the ID is not found within the 
authorization table 141, the requested program or overlay to 
not transmitted back to the requesting terminal 112. 

FIG. 3 shows an illustrative embodiment of the hardware 
architecture of the elements of the portable data collection 
terminals 112. Each terminal 112 includes a data bus 142 for 
interconnecting the elements of the terminal 112, which may 
include a ROM 144 for the bootstrap loader, a flash ROM 
150 for storing system and application programs, a static 
RAM (SRAM) 146 for storing data, programs and dynami- 
cally loadable program overlays, a microprocessor 140 
which may take the form of that processor made by NEC as 
a model V25, the radio module 152, a serial communication 
interface (U ART) 148 for the radio module 152, a bar coding 
scanning interface 149, a manual input system such as a 
keyboard 113 and a display 115. The serial communication 
interface 148 permit messages to be transmitted and 
received via the radio module 152. The keyboard 113 and the 
bar code scanning interface 149 permit data entry respec- 
tively by the terminal user and a CCD bar code scanner 
similar to those identified in FIG. 1 by the numeral 22. As 
is well known in the art, a scanner 22 would be moved across 
coded data to provide data descriptive of the item to which 



the bar code was attached, typically including a description 
of the item, its price and/or other inventory data. 

Appreciating that each tenminal 112 is battery operated, a 
plurality of memories 144, 146 and 150 are provided therein 
to store various types and sizes of data and programs 
dependent upon their use and to the end, that battery drain 
be minimized. The ROM 144 stores the operating system 
and basic input/output system (BIOS) for the microproces- 
sor 140. The SRAM 146 stores the dynamically loadable 
program overlays and data. The flash ROM 150 stores the 
system operating program and the application programs to 
be executed by the microprocessor 140, typically carrying 
out the various inventory functions for which a terminal 112 
may be programmed. A portion of the SRAM 146 is parti- 
tioned into tables for application specific data, i.e., data to be 
used by the stored application programs. It is a significant 
aspect of this invention, that not all of the application 
programs or application specific data which may be used by 
a terminal 112, should be stored in the SRAM 146, but rather 
that significant portions of the application programs and 
specific data may be stored in the database server 130 (or 
even in the host computer 118) to be accessed when needed 
by a particular terminal 112. 

The archectiture of the software stored in the flash ROM 
150 is shown in FIG. 4. The flash ROM 150 stores a plurality 
of application programs 154, e.g., inventory tracking, a 
program manager program 156 explained below with 
respect to FIG. 5 for transmitting the SQL request to the 
database server 130 to obtain an overlay module or a new 
program, a transaction manager 158 as explained below in 
detail with respect to FIG. 6 for opening a new session to 
receive or to transmit streams of data thereto, and a radio 
protocol stack 160 for effecting the RF transmission of a data 
stream out 161a to the database server 130 and for receiving 
an RF transmission via a data stream input 1516 from the 
database server 130. An application interface 155 is estab- 
lished between the application programs 154 and the pro- 
gram manager 156, whereby any of the application pro- 
grams can request the services of the program manager 156, 
40 which may be illustratively thought of as a collection of 
sub-routine calls for new overlay modules or a new program 
as will be explained below with respect to FIG. 5. Further, 
the application programs 154 have a transaction application 
programming interface (API) 157 with the transaction man- 
ager 158 as will be explained below with respect to FIG. 6. 
The transaction API 157 permits an application to transmit 
a SQL request to the database server 130. In turn, the 
transaction manager 158 has an interface 159 as exemplified 
by a NetBIOS with the radio protocol stack 160, which 
efifccts by RF transmission the sending and receiving of data 
to and from the database server 130. As indicated by the 
archectiture of the data stored within the flash ROM 150 
shown in FIG. 4, the radio protocol stack 160 is transparent 
with respect to an application program, i.e., the application 
program need not be programmed to effect radio transmis- 
sion but only to place a call to transmit or to receive data. 
Either the program manager 156 or the transaction manager 
158 carries out that step without any special program of the 
application programs 154. 

The database server 130, as shown generally in FIG J, 
may illustratively take the form of an IBM PS/2 model 80 
computer running IBM's OS/2 Extended Edition operating 
system. Generally, the database server 130 responds to a 
SQL request transmitted by a radio module 152 of a data 
collection terminal 112 (see FIG. 3), or from the host 
computer 118. The response of the database server 130 to the 
SQL request is determined by the semantics of that SQL 
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request, which is formatted in the ANSI standard SQL The 
database server 130 need not store state information about 
each of the terminals 112a, b~n. Data relating to a particular 
or specific terminal 112 is assigned to its own memory table, 
which may be illustratively formed at its unique address 
within a DRAM 136 of the database server 130 as shown in 
FIG, 7. That table for terminal specific data may be used at 
a bufifer, where the addressed location within the DRAM 136 
acts as a buffer memory to be addressed by a SQL request 
and in response thereto, to transmit the data stored in that 
buffer to the requesting terminal 112. Alternatively, the 
terminal specific data could be stored in the hard disk drive 
137 of the database server 130 and could be accessed by 
assigning an identifier attribute for that data to each terminal 
112, whereby the appropriate relation in the hard disk drive 
137 of the database server 130 could be defined. As will be 
explained, each SQL request identifies a new program, an 
overlay or application specific data which is required by the 
requesting terminal 112; the database server 130 responds to 
that request and transmits in turn the requested program, 
memory overlay or application specific data to the particular 
requesting terminal 112. 

FIG. 7 shows the hardware architecture of the database 
server 130, including a data bus 134 for connecting the 
various elements thereof, a microprocessor 132 illustrative 
taking the form of that processor manufactured by Intel 
under its model No. 80386, a ROM 135 for the computer 
powerup program, the diagnostic programs and the BIOS 
program, the dynamic RAM (DRAM) 136 serving as a 
memory for a database server program, server data, and a 
"cache" memory for the database, and a mass storage in the 
illustrative form of the hard disk drive 137 for storing all of 
the partitioned application programs and application specific 
data to be called by the plurality of terminals 112a, b-n. The 
database server 130 may provide gateway functions to other 
databases, e.g., DB2. In an operational sense, a gateway 
function permits access to a remote database by passing 
and/or reformatting the request. In other words, the SQL 
request could be translated into a format that would corre- 
spond and be recognized by that format of the remote 
database. 

Referring now to FIG. 3, the SRAM 146 of a portable data 
collection terminal 112 is significantly smaller than the disk 
drive 137 of a database server 130 and may have a capacity 
insufficient to store all of an application program and data to 
be executed by its microprocessor 140. Distributed process- 
ing is accomplished in the context of this data capture 
system 110 employing a plurality of terminals 112 and a 
database server 130, by partitioning each application pro- 
gram into a plurality of parts or second information portions 
or modules. The first program part is known as a root module 
and will be loaded first when a request for a new program is 
issued by the microprocessor 140 at power up or entered by 
a user through the terminal's key board 113. There will be 
at least one and typically many further parts or second 
information portion known as memory overlays or overlay 
modules. The root module and the overlay modules will be 
given unique identifiers so that they may be loaded when 
requested. When the microprocessor 140 is executing the 
last instruction of a root module or an overiay module, then 
it is necessary to request and retrieve the next overlay 
module to permit the application program to continue to be 
executed without interruption. As will be explained below, 
this data capture system 110 is capable of formatting a SQL 
request for that original program or root module and for the 
subsequent overlay modules. In the simplest embodiment of 
this invention, the programmer builds into the application 
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program a request to the program manager program 156 (see 
FIG. 4) to request and load an overlay module and jump to 
it. In a more sophisticated version, a program in the devel- 
opment environment determines the external function calls 

5 in program and substitutes a call to the program manager 
program 156. The development in partitioning of an appli- 
cation program is accomplished on the database server 130 
using a data collection terminal emulator system that emu- 
lates the keyboard 113, the display 115 and other possible 

10 peripherals of the terminal 112, The only programming to be 
done specific to the database server 130 is to create the 
database tables and load them with any application specific 
data. 

The software architecture of the DRAM 136 is further 

15 described in FIG. 8, as being partitioned to store a commer- 
cial database management system 212 such as the SQL 
Server (Microsoft), a database gateway 214, e.g., a DB2 
Gateway by IBM, a presentation manager 216 to be more 
fully disclosed in the flow diagram of FIG. 9, a network 

20 protocol stack 218, and a radio protocol stack 220. 

The program manager program 156 generally shown in 
the software architecture diagram of FIG. 4 is more fully 
shown in the flow diagram of FIG. 5. Basically, the program 
manager program 156 is disposed in the next lower layer 

25 below an application program, e.g., an inventory program, 
and responds to its request for either a new program or a 
memory overlay, to configure and transmit an SQL request 
to the database server 130. Upon receipt of the requested 
program or memory overlay, the program manager program 

30 156 stores it in SRAM 146 before initiating its execution by 
the microprocessor 140. A start 162 is initiated in a number 
of ways by the associated application program. At power up 
when typically there is no application being executed, the 
operating system program, which is stored in the ROM 144, 

35 places a call to the program manager 156. Alternatively, a 
new application program may be called by the operator by 
actuating a selected key(s) of the keyboard 113. Appreciat- 
ing that all of a particular application program need not be 
stored in the SRAM 146, overlay modules of the application 

40 program presently being executed may be stored in the 
database of the server 130 and may be called by the program 
manager program 156. The application program continues to 
be executed until it recognizes that the next step is not 
available, at which time it places a call through the start step 

45 162 for the next section or overlay module of the application 
program to be retrieved and placed in the SRAM 146 of the 
requesting terminal 112. 

After a start has been provided in any of these ways, step 
164 determines whether a new program or memory overlay 

50 is being requested. If a new program is requested, step 166 
accesses the database in the server 130 for the requested 
program. In particular, step 166 initiates the radio protocol 
stack program 160, whereby the radio module 152 (sec FIG. 
3) is activated to transmit the SQL request to the database 

55 server 130 via the transceiver 114 (see FIG. 2). The SQL 
request initiated by step 166 seeks as will be described 
below a list of programs which are stored in the database 
server 130 and is available to this originating terminal 112. 
Initially, step 166 calls the radio protocol stack program 160 

60 (see FIG. 2), whereby access is made through the UART 148 
(see FIG. 3) to the module 152, turning module 152 "on" to 
transmit the SQL request to the transceiver 114. In addition 
to actuating the radio module 152, the radio protocol stack 
160 provides the protocols and media access to allow the 

65 SQL request to be sent via the transceiver 114 to the database 
server 130. Illustratively, the radio protocol stack 160 would 
include the RTC system as described in U.S. Pat. No. 
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4,940,974. When the radio protocol stack 160 is called to response is received by the requesting terminal 112 within 
initiate transmission, a session is said to be held between the this period, step 176 generates a return error message and 
requesting terminal 112 and the database server 130. For returns it to the calling application program. On the other 
example, when a SQL request is generated by the transaction hand if the requested original program is received within the 
manager 158 (see FIG. 4, a session is opened. Each session 5 period, step 178 updates a mapping memory or table, which 
enjoys a logical relationship between the requesting terminal j^^y 5^ Ubstratively included within the SRAM 146 see 
112 and the database, e.g., the hard disk drive 137, within the piG. 3 of the terminal 112. A record of the application 
database server 130. Each session includes one or more data ^^^^^^ ^^^^^^^ presently being executed by the 
packets, the data packet being the maximurn byte size of the n^icroprocesor 140 is recorded in the mapping memory in 
data stream appcanng on the output l^la that may be ^^^^ ^^^^^^ ^^^^ ^^^^ ^ ^j^^ 
transmitted by the radio module 152. The radio protocol . ^ j 1 ^ j • . oi^ a*^ ^.^o 
stack 160 functions to segregate a data stream out 161« to be P'«8'?'° ."^ '^"^'".^'^ ""^ ° ^RAM 146, step 178 
transmitted to the database server 130, into a number of data '^"""^^ ''^ /'^^'°S . ^^'^'^ ^^"S.\ >n the mappmg 
packets and, in similar fashion, to reassemble the data tncmoiy, before loadmg the root modWe of new program 
packets of an incoming data stream appearing at the input '°!°. " designated locataon of the SRAM 146 and, thereafter, 
161fa into a continuous data stream. Each SQL request « i^'^a'^^ execution of the received and loaded program 
includes an address or ID of its originating terminal 112. As '"^'^d of returmng control to the application program. The 
will be explained later, the database server 130 uses a SRAM 146 is used as a cache memory to receive the 140 
presentation manager program 216 to store the relationship P^S''""^ memory overlap to be executed by the 
(mapping) between the terminal ID and the operating system microprocessor 140. Tlius, the SRAM 146 provides a local 
session identificer. which is stored in a known location ""«""°fy ^"'^ "^'^^ "'^ apphcation program may be 
within the DRAM 136 of the database server 130. In this ^^^^f- whereas the remaimng sections or memory over- 
way, the database server 130 remembers to which of the '"y^ °} application program and other origmal programs 
plurality of terminals 112^, t>-n that the requested data or ""7 d»s'a°"y database of the server 130. 
memory overlay, should be transmitted. , appreciated that apphcation piograins are sometimes 
The database server 130 operating as will be explained, ^ '"6^.^ « s sections or memory overlays. T]ierefore to 
will respond to the SQL request for a program overlay by efficientiy use the local memory, e.g., the SRAM 146 new 
accessing a list of programs authorized for the particular programs are illustratively stored m the database of the 
requesting terminal 112 or user and transmitting that list ^^^f ^^O, whereas prograin overlays may be stored m both 
back via fhe transceiver 114 to the requesting terminal 112. f^!^,"/^ !^'"^," 

Til ^. ™„„ cr^T ,«„„«^t tu« 30 the SRAM 146. Therefore, if step 164 determines that the 

Illustratively, step 166 may tormat an i>QL request in the .... . ^ 

following manner: application is not requesting a new program, but rather an 

overlay module, step 180 examines the SRAM 146 and if the 

requested overlay module is in SRAM 146, the program 

select distinct program_name from moves to stcp 178 to initiate exocution of the Overlay module 

authorization where user^id - "mormmd" 35 and control is passed to the overlay modulc. However, if the 

requested overlay module is not in the SRAM 146, step 180 
Here the SQL request is seeking a list of distinct programs, "»oves control moves to the transaction manager 158, which 
not duplicates, which have been authorized for transmission formulates and transmits a SQL request via the transceiver 
to a particular user, i.e., a particular terminal 112. In the to retrieve the needed overlay module from the database 
illustrative request, the user ID is "morrismd"; in other ^^^^ 130. The requested memory overlay is trans- 
words, aU program names having an ID attribute "mor- mitted back via the transceiver 114 and is loaded into SRAM 
rismd" are distributed to the requesting terminal 112. Next, l'*^ thereafter, the local mapping memory in SRAM 
step 168 displays the received list of authorized programs on 1"*^ ^ updated m terms of Us startmg address and length, 
the terminal's display 115 After step 174 determines that the requested program has 
In step 170 of FIG. 5, the terminal user selects from that '^^ been timely received as explained above, step 178 initiates 
list of available programs as displayed in step 168 and enters execution of the overlay module before returning control to 
via the terminal keyboard 113 the selected program to be ^^e application program. 

requested from the database of the server 130. When a Refemng now to FIG. 6, there is shown the transaction 

program is selected from the menu displayed upon the manager program 158 which responds to a call from the 

display 115 (see FIG. 2) by user actuation of the keyboard 50 application program 154 (see FIG. 4) for data to be pro- 

113. the transaction manager 158 (see FIG. 6) is caUed to messed thereby and provides an application programming 

format the SQL request to retrieve from the remote database i^^^rhcc (API) 157 to the application program which allows 

the particular program selected in step 170. An illustratively to access the database in the server 130. The transaction 

example of such a SQL request may take the form of: manager program 158 also supports the program manager 

55 program 156 to access programs stored in the database of the 
server 130. Thus, it is seen that the program manager 
select program from program_tab!e where program 156 of FIG. 5 acccsses second information portions 
program^name - "inventory.exe" and overlay - gych as remote programs and overlay modules whereas the 
transaction manager 158 of FIG. 6 accesses any kind of data. 

60 Initially, step 194 determines whether the requested data is 

Illustratively, the SQL request accesses the first, program in the local memory, i.e., SRAM 146, and, if so stored, step 

table 139 (see FIG. 7) to obtain the address in the hard disk 208 returns the local data to be processed by the application 

drive 137 of the requested program, e.g. the "inventory.exe" program. If not, step 196 formats an SQL request for the 

program, which is an original program or it's root overlay. requested data and step 198 calls the radio protocol stack 

Aftertransmissionof the SQL request for a new program, 65 program 160 (see FIG. 4) thus actuating the radio module 

step 174 waits for a returned message to the terminal 112 and 152 and transmitting the SQL request via the transceiver 114 

will time out after a set period, e.g., 30 seconds. If no to access the requested data in the database in the of the 
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server 130. Step 200 waits while the server 130 accesses the 
requested data and transmits it via the transceiver 114 to the 
requesting terminal 112. Step 200 times a response period, 
e.g., 1 minute, and if that period is exceeded indicating an 
error condition, step 202 returns an error message to the 
calling application program. If the data is received within the 
response period, step 204 formats the requested data in a 
form usable by the calling application program, before step 
206 returns that data to the application program. Step 206 
returns the data to the SRAM 146, whereby control is passed 
to the application program which uses the returned data. 

The presentation manager program 216, shown in FIG. 9, 
processes the SQL request transmitted from one of the 
terminals 112 (see FIG. 2) via the transceiver 114 and a 
standard interface, e.g. Unix sockets or IBM NetBIOS, to 
the database manager program 212 (see FIG. 8). The data- 
base manager program 212 interprets the SQL request and 
accesses the hard disk drive 137 accordingly (see FIG. 7). 
This allows an application program being executed by the 
microprocessor 140 (see FIG. 3) to establish sessions with 
any SQL accessible database as maybe formed within the 
hard disk drive 137 of the database server 130. The principle 
function of the presentation manager program 216 is to 
translate between that format used by the transaction man- 
ager program 158 of a terminal 112 and the SQL formal of 25 
the database of the hard disk drive 137, if these formats are 
different. The SQL request to be applied to the database 
management program 212 is semantically configured in 
accordance with the function to be achieved. The SQL 
request may direct that data be inserted in the disk drive 137, 30 
that data be accessed and retrieved, that a new program or 
overlay module be retrieved from the disk drive 137, that 
data be added to one or more fields in a set of records stored 
in the disk drive 137 or that data be deleted from one or more 
records of the disk drive 137. Updating involves the trans- 35 
mitting of new variable values from the originating terminal 
112. 

Referring now to the flow diagram of FIG. 9, the presen- 
tation manager program 216 enters through start step 230 to 
step 232, which wails for a SQL request to be forwarded 40 
from the radio protocol stack 220 (see FIG. 8). As will be 
described below, the SQL request is directed toward the 
database manager program 212. Step 234 receives the SQL 
request as a sequence of bytes. Step 236 comes into play 
only if some reformulation of the SQL request is necessary. 45 
In a first instance, if the database manager program 212 was 
not adapted to support the ANSI standard SQL format or if 
the SQL request was compressed, then step 236 would be 
necessary to decompress the data or to translate the format 
of the SQL request into that of the particular database 50 
manager program 212 employed in the system. Next, step 
236 provides the data to the database manager program 212 
through an interface in the illustrative form of the IBM 
NetBIOS interface. The translation step 236 is identical to 
the formatting request 196 of the transaction manager pro- 
gram 158 of FIG. 6 and, ordinarily, it would be only 
necessary to perform the formatting or translation step once 
upon a particular SQL request, preferably in the presentation 
manager program 216. Step 240 waits for the database 
manager program 212 to access the disk drive 137 for a 
predetermined time period. If the requested material, i.e., a 
second information portion such as the application specific 
data, root overlay or memory overlay, is received within the 
time period, it is translated in step 242 to the format of the 
requesting terminal 112, before calling the radio protocol 65 
slack program 220 to transmit the accessed material back to 
the requesting terminal 112. On the other hand, if the SQL 
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request is one to add or delete data from the hard disk drive 
137, step 240 generates a status message indicating that the 
change of the hard disk drive 137 has been completed, 
before step 242 translates that status message into the 
terminal format and the radio protocol stack 220 is called in 
step 244 to send that message back to the requesting terminal 
112. If the time period set in step 240 times out, without 
receiving the requested material, step 246 transmits an error 
pachet to the radio protocol stack program 220, whereby an 
error message is returned to the requesting terminal 112. 

Thus, there has been described a data capture system 110 
that distributes the application program between the memory 
of a terminal 112 and a database server 130 serving a 
plurality of such terminals 112. In this fashion, the com- 
plexity of the program to be executed upon a terminal 112 
is minimized by permitting the data base server 130 and its 
hard disk 137 to store a large variety of application programs 
to be served to its client terminals 112. The above data 
capture system 110 permits dynamic loading of the original 
programs or root modules and subsequent memory overlays 
from the hard disk 137, whereby the size of the SRAM 146 
of a terminal 112 and the power required by a terminal 112 
is minimized. Further, the amount of data transmitted via the 
RF link between each of the plurality of terminals 112 and 
the database server 130 is minimized. Further, the database 
server 130 provides a "user friendly" environment for the 
development of application programs for the terminals 112. 
In particular, the database server 130 is capable of readily 
developing both the client and server portions of the appli- 
cation programs to be executed by the terminal's micropro- 
cessor 140. 

It will be apparent that many modifications and variations 
may be effected without departing from the scope of the 
teachings and concepts of the present disclosure. 

We claim: 

1. A data collecting system for collecting data from at 
least one remote site and transmitting the collected data to a 
main information center, and having information distributed 
throughout said data collecting system, the information 
being partitioned into a first information portion and a 
second information portion, said data collection system 
comprising: 

at least one terminal for collecting data at the remote site, 
said terminal comprising a data collection mechanism, 
a first memory for storing the first information portion, 
a first controller responsive to the need for information 
by said terminal to generate an information call iden- 
tifying the needed information, said first controller 
further responsive to the information call by searching 
said first memory for the presence or absence of that 
needed information, said first controller responsive to 
the presence of that needed information by accessing 
said first memory and supplying that accessed, needed 
information for use by said terminal; 

a server for said terminal; 

a communication system communicatively interconnect- 
ing said terminal and said server, said first controller 
responsive to the absence of that needed information 
within said first memory by transmitting the informa- 
tion call via said communication system from said 
terminal to said server; and 

said server disposed at the main information center and 
comprising a second memory for storing the second 
information portion, and a second controller responsive 
to the information call transmitted via said communi- 
cations system from said terminal by accessing the 
requested information from said second controller and 
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transmitting the accessed information via said commu- 
nication system from said server to said terminal. 

2. The data collecting system as claimed in claim 1, 
wherein the information comprises a plurality of application 
programs, the first information portion comprises a root 
module and the second information portion comprises at 
least one overlay module, said terminal comprising a pro- 
cessor for executing a selected one application program, and 
said first controller responsive during the executing of the 
root module by said processor to generate the information 
call requesting a particular overlay module. 

3. The data collecting system as claimed in claim 2, 
wherein the second information portion also comprises 
application specific data and a request encoded within each 
of said application programs for the corresponding applica- 
tion specific data, said first controller responsive during the 
execution of one of said pluralities of the application pro- 
grams by said processor to generate the information call for 
the corresponding application specific data. 

4. The data collecting system as claimed 2, wherein said 
terminal comprises a keyboard for user entry of a request for 
a root module for a new application program of said plurality 
thereof, said first controller responsive to the root module 
request by generating in turn the information call thereof. 

5. The data collecting system as claimed in claim 1, 
wherein said communication system is wireless. 

6. The data collecting system as claimed in claim 5, 
wherein said terminal comprises a first radio and said server 
comprises a second radio, said communication system com- 
prising said first and second radios. 

7. The data collecting system as claimed in claim 6, 
wherein said first controller is responsive to the absence of 
the requested information within said first memory by 
actuating said first radio. 

8. The data collecting system as claimed in claim 6, 
wherein said second controller is responsive to the receipt of 
the information call to actuate said second radio. 

9. A data collection system comprising: 

a portable terminal having processing circuit and a 
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the portable terminal displays the listing of application 
programs for selection; 

the portable terminal attempts to locate each portion of a 
selected one of the plurality of application programs as 
needed from the memory, but, if the portable terminal 
fails to locate the at least portions of the plurality of 
application programs in the memory, the portable ter- 
minal generates information calls and communicates 
the information calls to the first computing device; and 

the first computing device attempts to service the infor- 
mation calls, but, if the attempt fails, the first comput- 
ing device forwards the information calls to the second 
computing device for servicing. 

10. The data collection system of claim 9 wherein the 
computer network is located at a remote location from the 
portable terminal. 

11. The data collection system of claim 9 wherein the first 
and the second computing devices comprise server devices. 

12. The data collection system of claim 11 wherein the 
information calls comprise SQL statements. 

13. The data collection system of claim 10 wherein the 
first and the second computing devices comprise server 
devices. 

14. The data collection system of claim 13 wherein the 
information calls comprise SQL statements. 

15. A data collection system comprising: 

a main information center with a plurality of servers, each 
server storing a plurality of application programs and 
associated application-specific data; 

a plurality of remote data collection centers, each data 
collection center comprising one or more terminals; 

each of the one or more terminal selectively requests the 
application programs from the main information cen- 
ter; and 

the main information center delivers requested ones of the 
application programs in executable portions. 

16. The data collection system of claim 15 wherein the 
terminal establishes a communication link with the main 



memory that both selectively stores at least portions of 40 information center to deliver the requests, and the requests 



a plurality of application programs, and stores a listing 
of the plurality of application programs; 
a computer network comprising a first computing device 
and a second computing device, each computing device 
stores at least portions of the plurality of application 
programs; 



are selectively forwarded to at least one of the plurality of 
servers for servicing. 

17. The data collection system of claim 16 wherein the 
requests comprise SQL statements. 
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